In a prior art network based storage backup system shown in FIG. 1, a system administrator usually schedules a backup of a source file system 101 or a part of the source file system on a file server 100 via a Network Backup Master (NBM) 104. A file system is an independently managed, self-contained, hierarchal set of data units (e.g., files, bocks or Logical Unit Numbers (LUNs)). Although a volume or file system (as those terms are used herein) may store data in the form of files, that is not necessarily the case. That is, a volume or file system may store data in the form of other units, such as blocks or LUNs. The NBM 104 then coordinates the backup process between the file server 100 and a Media Server (MS) 105, which receives a backup image of the source file system 101 or a part of the source file system and stores the backup image into various target backup devices, such as a tape device 106, a disk storage unit 107, and/or a Virtual Tape Library (VTL) 108, etc. The NBM 104 communicates with the file server 100 via a Network Backup Unit (NBU) 102 of the file server. The file server 100 is coupled with a storage subsystem 103, which contains the actual data of the file system 101.
In some cases, a backup image of the file system 101 or a dataset within the file system (a list of directories and files in the file system, for example) may be in a compacted or archival format (a sequential format such as a .tar file, for example), instead of in the file system or the dataset's original format (directory structured format, for example). In other words, rather than being a literal (or physical) duplicate of the source (a persistent point-in-time image of the source, for example), a compacted backup image of the source is a logical copy with a different structure or format. For illustration purposes, the term “backup image” refers to compacted or archival backup image in the present application. FIG. 2 illustrates an example of creating a backup image 202 of a directory structured file system 201. In order to create a backup image of a file system or a part of the file system, a format must be followed so that the file system or the part of the file system may be recovered from the backup image. Each software vendor may use its own format. For example, the backup image 202 may capture the metadata of the file system 201 (i.e., pathname, security, attributes of the system's files) in the vendor's proprietary format. As a result, the vendor's software is needed to utilize the backup image 202 or a part of the backup image (one or more files contained in the backup image, for example). FIG. 3 is a block diagram illustrating a prior art mechanism of utilizing a backup image for multiple purposes. As shown, a vendor specific software or control logic 301 receives a backup image 302 and analyzes it according to its format to create an expanded view of the backup image 303 or to create an expanded version of the whole backup image or any part of the backup image 304. An expanded view of a backup image of a dataset may be, for example, the directory structure of the dataset including the list of files under each directory. An expanded version of the whole backup image may be, for example, an extracted copy of the backup image. An expanded version of a part of the backup image may be, for example, an extracted copy of one or more files within the backup image. The backup image should be kept unchanged so that it may be used to restore the file system back to the state when the backup image was created, if necessary (e.g., in the event of a major failure causing loss of data). Thus, multiple copies of an expanded version of the whole backup image or any part of the backup image 304 need to be created so that each copy may be used for a different purpose that may involve modification or deletion of any data thereof. However, this mechanism is very inefficient in storage usage, because in most cases there are a lot of data redundancies among these copies created even if each copy may undergo some change. This inefficiency tends to get worse as the size of each copy gets larger. In addition, the creation of each of these copies takes time. When there are many simultaneous requests targeting one backup image, the waiting time in creating these copies becomes longer.